test(runtimes): check that generated modules actually run - #31
Closed
TomChv wants to merge 2 commits into
Closed
Conversation
TomChv
force-pushed
the
feat/runtime-execution-tests
branch
2 times, most recently
from
August 25, 2026 16:06
33da82f to
c0a0499
Compare
TomChv
marked this pull request as ready for review
August 25, 2026 16:15
eunomie
approved these changes
Aug 26, 2026
TomChv
force-pushed
the
feat/runtime-execution-tests
branch
from
August 28, 2026 11:24
c0a0499 to
8cde01f
Compare
TomChv
force-pushed
the
feat/runtime-execution-tests
branch
from
August 28, 2026 12:26
8cde01f to
2feb073
Compare
Every other check inspects what generation writes. None loaded the result — so the contract the whole move rests on was verified only by hand: sdk/ resolving as @dagger.io/dagger, the bundle it holds being loadable, the entrypoint importing the user's classes and registering them. A break there is a module that generates cleanly and fails at `dagger call`. Loading a module is enough to force it. A dagger-module.toml module does no codegen at call time, and the TypeScript SDK has no ModuleTypes function, so reading its objects builds the runtime container and executes the generated entrypoint. One fixture per runtime, because this is where they stop being interchangeable: generation differs only in which config file it writes, but node, bun and deno each execute the entrypoint in a different container with a different interpreter. Bun had never been run at all — it was dismissed as taking node's code path, which is true of generation and false of execution. Staged with withChanges rather than written to disk, which also keeps the fixtures free of generated output and sidesteps a module's own .gitignore hiding its generated files from the engine's module context. Confirmed each check fails when the fixture's object is renamed. Signed-off-by: Tom Chauveau <tom@dagger.io>
Loading a module proves the entrypoint registers its types. This proves the other half of the dispatcher: that a call reaches the user's code and its return value comes back. sdk-sdk's harness already drives a release CLI through the whole user path — `sdk install`, `module init`, `generate` — so the call is one more command on the state it leaves behind. What its harness cannot do is init with a `--runtime` flag: initArgs is private and fixed, and a run's container is not exposed, so the per-runtime checks still build their own module. A seam there would be worth proposing upstream. The function is the default template's baseImageAddress, whose value the module's constructor sets, so a passing call also means the constructor ran and its default was applied. Confirmed by changing that default and watching the check report the new value. Signed-off-by: Tom Chauveau <tom@dagger.io>
TomChv
force-pushed
the
feat/runtime-execution-tests
branch
from
August 28, 2026 13:17
2feb073 to
a11b109
Compare
Member
Author
|
Superseded by #39, which squashes this whole stack into a single PR off The stack had PRs overwriting each other — this one included — which made the intermediate states hard to reason about, and thirteen PRs each fanning out a full check suite made CI unreadable. Branch is left pushed, so nothing here is lost. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Every other check inspects what generation writes. None loaded the result — so
the contract the whole move rests on was verified only by hand: sdk/ resolving
as @dagger.io/dagger, the bundle it holds being loadable, the entrypoint
importing the user's classes and registering them. A break there is a module
that generates cleanly and fails at
dagger call.Loading a module is enough to force it. A dagger-module.toml module does no
codegen at call time, and the TypeScript SDK has no ModuleTypes function, so
reading its objects builds the runtime container and executes the generated
entrypoint.
One fixture per runtime, because this is where they stop being interchangeable:
generation differs only in which config file it writes, but node, bun and deno
each execute the entrypoint in a different container with a different
interpreter. Bun had never been run at all — it was dismissed as taking node's
code path, which is true of generation and false of execution.
Staged with withChanges rather than written to disk, which also keeps the
fixtures free of generated output and sidesteps a module's own .gitignore
hiding its generated files from the engine's module context.
Confirmed each check fails when the fixture's object is renamed.
Signed-off-by: Tom Chauveau tom@dagger.io
Stack created with GitHub Stacks CLI • Give Feedback 💬